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FIELD OFTHE INVENTION 

The present utvention relates to network syncfaronizatiGn and more particulady to 
1 0 sjTichionizmg the playback of a multimedia event on a plurality of client 
apparatuses. 



BACKGROUND OF THE INVENTION 

15 

Systems such as the Jntemet ^ically are point-to-point (or unicast) sy^ems in 
which, a message is converted into a seri^ of addressed packets which are routed 
Sxxm a source node through a plurality of routers to a destination node. Tn most 
commuuication protocols the packet includes a header which contains I3it addresses 
20 of the source and the destination nodes as well as a sequence number which specifies 
the packef s order in the m^age. 

hi general, these systems do not have the ce^ability of broadcasting a message firom 
a source node to all the other nodes in the network because sndi a capability is rarely 

25 of much nse mi could easily overload the network. H6wev^» there are situations 
where it is desirable for one node to conmiumcate with some subset of all the nodes. 
For example, multi-party conferencing capability analogous to &at found in the 
public telephone syst^ and broadcasting to a limited numb^ of nodes are of 
considerable interest to users of packet-switched networks. To satisfy such 

30 demands, packets destmed for several redpients have been encapsulated in a imicast 
packet and forwarded firom a source to apoint in a network where the packets have 
been rq>Iicated and forwarded on to all desired recipients. This technique is known 



k 



as IP Multicasting and the network over which such packets are routed is referred to 
as fhe Multicast Backhone or MBOKB. More recmtly, routers have become 
available vMch can route the multic^ addresses (class D addresses) provided for in 
conmiunication protocols such as TCP/IP and UDP/IP. A multicast address is 
5 essentially an address for a group of host computers who have indicated their de^ 
to participate in that groiip. Thus, a multicast packet be routed firom a source 
node ftrougjx a plurality of multicast routers (or n[Uoute3:s) to one or more devices 
receiving fte multicast pack^. From there tiie packet is distributed to all the host 
computers that are members of the multicast groiQ). 

10 

These techniques have been used to provide on the Mem^ audio and video 
conferendng as well as ladio-like broadcasting to groups of interested parties. See, 
for example^ EL Savetz et al. MBQNE Multicasting Tomorrow's Internet (IDG 
Books Worldwide Inc., 1996). 

15 

Further details concerning technical a^ects of multicasting may be Jfonnd in the 
Memet documents Request for Comments (RFC) 1112 and 1458 which are 
reproduced at Appendices A and B of die Savetz book and in D. P. Brutaman et al., 
"MBONB provides Audio and Video Across the hxtemet," IEEE Computer, Vol. 27, 
20 No. 4, pp. 30-36 (April 1994), all of which are incorporated herein by reference. 

Multimedia computer systems have become increasingly popular over the last 
several years due to fteirvea:satiHtyaiid their interactive presentations^^ A 
multimedia computer system can be defined as a computer system having a 

25 combination pf video and audio outputs for presentation of audio-visual displays. A 
modem multimedia computer system typically includes one or more storage devices 
such as an optical driven a CD-ROM, a hard drive, a videodisc, or an audiodisc, and 
audio and video data are typically stored on one or more of these mass storage 
devices. In some file formats the audio and video are interleaved togedier in a single 

30 file, while in other formats the audio and video data are stored in difTerent files, 
many times on diBerent storage media* Audio and video data for a multimedia 
display may also be stored in separate computer systems that are netwodced together. 
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Jn tiiis instance, die computer system presenting tibie mnltunedia display would 
receive a p orti on of the necessaiy data fiom the oth^ computer ^tem via the 
network cabling. 

5 Graphic images used in Windows multimedia a^pficalions can be cheated in eith^ of 
two ways, fliese bemg bit-mapped images and vector-based images. Bit-m^ed 
images conoprise a plurality of pictore demits (pixels) and are created by assigoing 
a color to each pixel inside flie image boundary. Most bit-m^ped color images 
require one byte per pixel for stomge, so laige bit-mapped images create 

10 correspondingly large files. For example, a fuU-screeii^ 256-coIor image in 640-by- 
48&{>ixel VGA mode requires 307,200 bytes of storage, if the data is not 
compressed. Vector-based images are cieated by defining die end points, thidmess, 
color, pattern and curvature of lines and soHd objects conqirised within &e image. 
Thus, a vector-based image includes a definition which consists of a numerical 

15 representation of the coordinates of &e object, refermced to a comer of the image. 

Bit-mapped images are the most prevalent type of hnage storage format, and the 
most common bit-m^ped-image file formats are as follows. A file fi)imat referred 
to as BMP is used ibr Windows bit-m^ files in 1-, 2-, 4-, 8-> and 24-bit color 

20 depths. BMP files contain a bit-map header that define the size of the inaage, the 
number of color planes, the type of compression used (if any), and the palette used. 
The Windows DIB (device-independent bit-map) format is a variant of the BMP 
format that includes a color table defining the RGB (red green bhie) values of the 
colors used. Oifa^ types ofbit-m£^> formats iziclnde the TIF (tagged image format 

25 file), the PCJX (Zsofi Personal Computer Paina>nish Bitmap) file formal, the GIF 
(graphics interchange file) format, and &e TGA (Texas Instnunents Graphic 
Architecture) file format. 

Hie standard ^^dows format for bit-m^ped images is a 2S6-color device- 
30 independent bit map (DIB) with a BMP (the Windows bit-mEq[>ped file format) or 
sometimes a DIB extension. The standard Windows format for vector-based images 
is referred to as WMF (Windows meta file). 



FuU-motion video implies tibiat video images Sxam on the con^ut^s sciueD 
simfulate those of a television wiHx identical (30 fiames-per-secand) fiame lates, 
and ftat&eseiniages are accompanied by lugh-qualitysteF^ Alaige 
5 amount of storage is required for high-resolution color images, not to mention a fidl- 
motion video sequence. For exacoplc;, a singje fiame of NTSC video at 640-by-400- 
pixel resolution with 16-bit color requires S12K of data per fiame. At 30 flames per 
second, over 15 Megabytes of data storage are required for each second of fidl 
motion video. Due to the large amount of storage required for fiill motion video, 
1 0 various t^pes of video conqiEression algorithms are used to reduce the amount of 
necessary storage. Video conqpression can be performed eith^ in real-time, ie*, on 
die fly durmg video c^ture, or on the stored video file after flie video data has b een 
c^tured and stored on the media, hi addition, different video compression mettxods 
exist for still graphic images and for full-motion video. 

15 

Exanq)les of video data compression for still graphic images are RLE (nm-Iength 
encoding) and JPEG (Joint Photographic Experts Groiq))compr6ssi RLE is the 
standard compression mediod for Windows BMP and DIB files. The RLE 
compression method pp^tes by testing for duplicated pixels in a single line of flie 

20 bit map and stores the number of consecutive duplicate pixels rather than the data for 
the pixel itself JPEG compression is a groi^ of related standards that provide either 
lossless (no image quality degradation) or lossy ^perceptible to severe 
degradation) compression types. Althou^ JPEG conqiression was designed for the 
compression of stiU images ralhor than video, seveial manufactureis siq)ply JPEG 

25 compression ad^ter cards for motion video plications. 

In contrast to compression algorithms fi>r still images, most video compression 
algorithms are designed to compress fiill motion video. Video compression 
algoritimis far motion video generally use a concept referred to as interfiame 
30 compression, which involves storing only fiie diff^ences between successive frames 
in the data file, hiterfiame conqiression begms by digitizing the entire image of a 
key fiame. Successive frames are compared with fiie key fiame, and only the 




differences betwem the digitized data ftom the key frame and fiom the successive 
frames are stored Periodically, soch as when new semes are displayed, new key 
frames are digitized and stored, and subseqaent conq[)arisons begin from this new 
reference point Tt is noted that interfiame compression ratios are content-dependent, 
5 i.e., if the video clip being compressed includes many abnq>t scene transitions from 
one image to another, &e compr^on is less efficient Exaxiq}les of video 
compression which use an interframe con^iession technique are MPEG, DVI and 
frideo, among others. 

10 MPEG (Moving Pictures Experts Groiq[>) compression is a set of methods for 

con^re^on and decompression of full motion video images ftat uses the intetframe 
coir^nression technique described above. The MPEG standard requires that sound be 
recorded simultaneously with the video data, and the video and audio data are 
interleaved in a single file to attempt to maintain the video and audio synchronized 

IS during playback. The audio data is typically compressed as well, and ttie MPEG 
standard specifies an audio compression method referred to as ADPCM (Adaptive 
Differmtial Pulse Code Modulation) for audio data. 

A standard referred to as Digital Video frtteractive (DYI) fonnat developed by hitel 
20 Corporation is a compression and storage fr)rmat for fiiU-motion video and high- 
fidelity audio data. The DVI standard uses intead&ame compression techniques 
similar to that of the MPEG standard and uses ADPCM compression fr»r audio data. 
The conq>res8iQn method used in DVI is referred to as RTV 2.0 (real time video), 
and this compression method is incorporated into Intel's AVK (audio/video kernel) 
25 software for its DVI product line. IBM has adopted DVI as the standard fr>r 

displaying video for its Ultimedia product line. The DVI file finrnat is based on the 
Intel i7S0 chq>5et and is supported through the Media Control Interface (MCI) for 
Windows. Microsoft and Intel jointly announced fiie creation of die D V MCI 
(digital video media control interface) command set for Windows 3. 1 in 1992. 

30 

The Microsoft Audio Video Ihterieaved (AVI) fi>rmat is a special compressed file 
structure format designed to enable video images and synchronized sound stored on 



GO-ROMs to be played on PCs with standaid VGA displays and audio adapter 
cards. Tlie AVI conipiesdonmetliodiises an interfile me^ 
between successive frames are stored in a manner similar to the compression 
methods used in DVI and MPEG. The AVI format uses ^onmetrical software 
5 con9ression-decon:^ression techniqaes, ie«, both conqpression and decompression 
are performed in real time. Thus AVI files can be created by recording video images 
and sound in AVI format fiom a VCR or television bro adcast in real time» if enough 
free hard disk space is available. 

10 Despite these compression algorithms, it is very difScult to simultaneously multicast 
multimedia mat^ial due to bandwidth restraints. This problem is unavoidable with 
present technology since such large amounts of data must be transfened over 
netwodcs such as the hitemet fiom a single host s^er to numerous dieot 
oonrputeis. 
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SUMMARY OF THE INVENTION 



A s^etn, method and article of manu&ctuie are provided for synchronizmg an 
event on a plurality of client i^aratuses. First, a plurality of client s^paratuses are 
S connected via a netwozk. Next an appHcationpiogram is embedded on a site on the 
netwoik. ^ use, information is requested fiom a senrer on the netwodcutilizi^ 
fqppHcation prog^raitu Such information relates to an event to be played back 
simultaneously on the client s^aiatuses* la response to such request, a script is 
received for dkplaying the infonnation. 

10 

In one embodiment of the present invention, Hlo application pmgram is further 
adspUd to send a request to letdeve conunands fiom the server fbir use with a 
playback device of one of the client £^paratuses. In accordance with a primary 
aspect of the present invention, the playback device includes a digital video disc 
15 pVD)playCT. 

In another embodiment of the present inv^tion, &e conomands may be ad^ted to 
playback the event on the playback device simultaneous with the playback of the 
event on tiie remaining chent apparatuses. Further, the command may include a start 
20 time when the playback of tiie event is to begin on each of the client ^paratuses. Li 
one aspect of die present invention, the apphcation program is a JAVA applet and 
the script is JAVAscripL 



BRIEF DESCRIPTION OF THE DRAWINGS 



The invention will be better understood when consideration is given to tfie following 
detailed description thereo£ Such description makes reference to the annexed 
drawing wherein; 

Figure 1 is a schematic diagram of a hardware inqilemoxtation of one embodiment 
of &e present invrotion; 

Figure 2 illustrates a flowchart delineating a method for synchronizing an event on a 
plurality of client ^aratuses in accordance with one embodiment of the present 
invention; 

Figure 3 illustrates a flowchart delineatiiig a method for storing synchronization 
in&rmation for subsequent playback of an event in accordance with one 
embodiment of the present invention; 

Figure 4 illustrates a flowchart setting fordi a method for providing overlays during a 
synchronized event on a plurality of client ^aratuses in accordance with one 
embodiment of fiie present invention; 

Figure 5 illustrates a flow diagram for delayed synchronisation of an event on a 
plurality of climt apparatuses in accordance with one embodiment of the present 
invention; 

Figure 6 illnstrates a flow diagram for providing information on a synchronized 
event on a plurality of client apparatuses in accordance with one embodiment of the 
present invention; 

Figure 7 illustrates a m^od for seating a syndironizo* object in order to playback 
an event simultaneously on a plurality of client apparatuses in accordance with one 
embodiment of the present invration; 




Figure 8 ilhisfrates a flowchart for affording a scheduler object ad^ted to fedlitate 
the plkyback of an event sbmiltaneoxisly on a plm^lity of networked client 
apparatuses in accordance with one embodim^ of the present invention; 

5 

Figure 9 is a flowchart delineating a method for identij^ing a plurality of events 
which are played back sinndtaneously on a plurality of networked client i^iparatases 
in accordance wift one embodiment of the present invention; 

10 Figure 10 shows a flowchart delineating a technique for interfacing a plurality of 
differeat types of playback devices of client apparatuses which are networked to 
simultaneonsly playback an event in accordance with one embodiment of the present 
invention; 

IS Figure 11 illustrates die manner in which a layer factory is created in accordance 
widi one embodiment of ^ presoit invention; 

Figure 12 illustrates the manner in i^^diich user requests are processed in accordance 
with one embodimeot of the present invention; 

20 

Figures 13-16 illustrate various class/component diagrams in accordance with one 
embodiment of tJie present invention; 

Figure 17 ilixistrates a logical sequmce diagram in accordance with one embodiment 
25 of the present invention; 

Figure 18 iUustrates a logical sequence diagram that shows server side collabomtion 
in accordance with one embodiment of the present invention; and 

30 Figure 19 illustrates a logical sequence diagram showing cUent side collaboration in 
accordance with one embodiment of the present invention. 



DETAILED DESCRIPTION OF THE PREBERKED EMBODIMENTS 

Figures 1-19 ilhistrate a system for syzxcliroziudxiig an evmt on a plurality of client 
q)paratases. Pdor to use^ an eyeat is stored in lo^ory on at least one of the client 
5 ^paiatuses. Such client e^aiatuses are ad^ted to be connected to a netwoik along 
vnih a host computer(s). In op^:ationy infonnation is transmitted jGcom the host 
conqint^ to the at least one client apparatus ntilizmg the netwoik. This in&nnation 
allows jfor the ^ultaneous and synchronous playback of the event on each of the 
client apparatuses. 

10 

In various embodiments, the clioit apparatuses may t^ the form of conq>uters, 
televisions, storeos, home qipliances, or any other types of devices. In one 
embodiment^ the client apparatuses and die host compute each include a computer 
such as an IBM con^atible computer, Apple Macintosh computer or UNIX based 
15 workstation. 

A repiesentative hardware environment is depicted in Figure 1, which illustrates a 
typical hardware configuration of a woikstation in accordance with a preferred 
embodiment having a central processing unit 110, such as a microprocessor, and a 

20 number of other units interconnected via a system bus 112. The workstation shown 
in Figure 1 includes a Random Access Memory (RAM) 114, Read Only Memory 
(ROM) 116, an 1/0 sdaptex 118 for comiecting peripheral devices such as disk 
storage nnits 120 (La DVD playback device) to the bus 112, a usct intec&ce ad^t^ 
122 for connecting a keyboard 124, a mouse 126, a speaker 128, a microphone 132, 

25 and/or other user interface devices such as a touch screen (not shown) to the bus 

112, communication ad^ter 134 for coxmectiog the workstation to a corrunuuication 
network (ag, a data processing network) and a display adapter 136 for connecting 
the bus 112 to a display device 138. The workstation typically has residmt thereon 
an operating system such as the Microsoft Windows NT or Windows/95 Operating 

30 System (OS), the IBM OS/2 operating system, the MAC OS, or UNK opOTtmg 
system. Those skilled in the art will appredate drat the present invention may also 
be implemented on platforms and operating systems other than those mentioned 
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A preferred embodim^t is written using JAVA, Q and the C++ language and 
utilizes object oriented programming methodology. Object orimted progranmung 
(OOP) has become incareasingly used to develop complex q)plications. As OOP 
moves toward the mainstieam of software design and development, various software 
solutions require adaptation to make use of the benefits of OOP. A need exists for 
these principles of OOP to be applied to a messaging inter&ce of an electronic 
messagmg system such that a set of OOP classes and objects for the messaging 
interface can be provided. 

OOP is a process of developing computer software using objects, including the steps 
of analyzing the piobl^> designing the system, and constructing the prograrru An 
object is a software package that contains both data and a collection of related 
stmctures and procedures. Since it contains both data and a collectioa of structures 
and procedures, it can be visualized as a self-sofScient conq)onent that does not 
require other additional structures, procedures or data to perform its specific task. 
OOP, therefore, views a conq>utear program as a collection of largely autonomous 
components, called objects, each of which is responsible for a specific task* This 
concept of packaging data, structures, and procedures together in one conxponent or 
module is called encapsulation. 

In general, OOP coroponeats are reusable software modules ^^ch preset an 
inter&ce that conforms to an object model and which are accessed at run-time 
through a compon^ integration architecture. A conxponent integration architecture 
is a set of architecture mechanisms whidi allow software modules in different 
proce^ spaces to utilize each otiiers c^abiHties or functions. This is generally done 
by assuming a common component object model on which to build the architecture. 
It is worthwhile to differentiate between an object and a class of objects at this point 
An object is a single instance of the class of objects, which is often just called a 
class. A class of objects can be viewed as a bluq)rint, from which many objects can 
be formed 
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OOP allows the programmex to create an object that is a part of another object For 
example, &e object representing a piston engme is said to have a com^stfionr 
relalioDsiiip with the object represeotmg a piston. In reality, a piston engme 
comprises a piston, valves and many other components; the fact fhzt a piston is an 
S element of a piston engine can be logically and semanticalfyr^resented in OOP by 
two objects. 

OOP also allows creation of an object that **depends £x>m'* another object If 1h^ 
are two objects, one representing a piston engine and the other representing apiston 

10 enable wherein the piston is made of ceramic, then &e relationship between tbie tv^o 
objects is not that of composition. A ceramic piston engine does not make up a 
piston engine. Rather it is merely one kind of piston engine that has one more 
limitation than the piston engine; its piston is made of ceramic, hi this case, &e 
object represraiting the ceramic piston engine is called a derived object and it 

15 inherits all of the aspects of the object representmg the piston engine and adds 
furdier limitation or d^ail to it The object representing the ceramic piston aigine 
"depends from** the object representing the piston engme. The relationship between 
these objects is called inheritance. 

20 Whea the object or class representing the ceramic piston engine inherits all of the 
aspects of the objects representing the piston engme^ it inherits the thermal 
characteristics of a standard piston defined in the piston engine class. However, the 
ceramic piston engine object overrides these cmmic specific thermal characteristics, 
which are typically different fix>m those associated with a metal pistoxL It sldps over 

25 fte original and nsesriew functions related to ceramic pistoiis. Differ^ kinds of 
piston engines have different characteristics, but may have the same underlying 
functions associated with it (e.g., how many pistons in the engine, ignition 
sequences, lubrication, etc.). To access each of Aese functions in any piston engme 
object, a programmer would caQ the same functions with the same names, but each 

30 type of piston ^gine may have diff^ent/ovemding implementations of functions 
behind the same name. This ability to hide different inoplementations of a fimction 
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behind Hxe same name is called polymoiphism and it greatly siinplifies 
commttnication among objects, 

Wi& tbe concepts of coixiposition-re]ationship, ^(^50^ 
5 poIymoipMsin, an object can represent just aboiitanyt^^ Itiiacty 
one^s logical perception of the reality is tbe only limit on determining the kinds of • 
things that can become objects in object-oriented software. Some typical categories 
are as follows; 

• Objects can represent physical objects, such as automobiles in a traffic-flow 

1 0 simulation, electrical conxpon^its in a drcait-de^gQ program, comitries in an 

economics model, or aircraft in an air-trafSc*control system. 

• Objects can represotit elements of the computer-user enviromnent such as 
windows^ menus or gr^Mcs objects, 

• An object can represent an inventory, such as a personnel jQle or a table of the 
15 latitudes and longitudes of cities. 

• An object can represent user-defined data types such as time» angles, and 
con^ilex numbers, or points on the plane. 

With tbis enormous capabihty of an object to represent just about any logically 
20 separable mattes, OOP allows &e software developer to design and implement a 
computer program that is a model of some aspects of reahty, whether that reality is a 
physical entity, a process, a system, or a composition of matter. Since &e object can 
represent anything, the software developor can create an object which can be used as 
a compozrent in a larger software project in the ftiture. 

25 

If 90% of a new OOP software program consists of proven, existing components 
made from preexisting reusable objects, then only the remaining 10% of flie new 
software project has to be written and tested ftom scratch. Since 90% already came 
fiom an inventory of extensively tested reusable objects, the pot^tial domain fiom 
30 which an error could originate is 10% of the program. As a result, OOP enables 
software developers to build objects out of other, previously built objects. 
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This process closely reseanbles complex machine bdng built out of assemblies and 
sub-assemblies. OOP technology, therefore, makes software engineering more like 
hardware engineering in that software is built fbom existing conq>on^ts, which are 
5 available to the developer as objects. All this adds up to an inq>ioved quality of the 
software as well as an inoreased speed of its development 

Programming languages are be^nning to fiiUy support the OOP principles, such as 
enc^sulation, inheritance, poj^oiphism, and composition-relationship. With ihc 

10 advent of the C4+ language, many commercial software developers have embraced 
OOP. OH- is an OOP language that ofiare a fest, machine-executable code, 
Furttiennore, C-H- is suitable for botfi commercial-application and systems- 
programming projects. For now, C-H- appears to be the most popular choice among 
many OOP programmers, but there is a host of other OOP languages, such as 

15 Smalltalk, Conunon lisp Object Systan (CLOS), and Eiffel Additionally, OOP 
capabilities are being added to more traditional popular computer programming 
languages such as Pascal 

The benefits of object classes can be summarized, as follows: 
20 • Objects and their correq)onding classes break down complex pmgranmring 
j)roblems into many smaller, simple problems. 

• Encq)5uIation enforces data abstraction through the organization of data into 
small, independent objects that can communicate witii each otii^. 
Encapsulation protects Ae data in an object fiom accidental damage, but 

25 allows other objects to interact with that data by calling the object's member 

ftmctions and structures. 

• Subclassing and inheritance make it possible to extend and modify objects 
through diving new kinds of objects ftom the standard classy available in 
the system. Thus, new c^abilities are created without having to start fiom 

30 scratch. 
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• Polymotphism and multiple inheritance make it possible for different 
pTogrammers to mix and matoh characteristics of many different classes and 
create specialized objects that can still work with related objects in 
predictable wa^. 

• Class hierarchies and containmeait hierarchies provide a flexible mechanism 
for modeling real-world objects and the relationships among tfaenL 

• libraries of reusable classes are usejEuI in many situations, but they also have 
some limitations. For example: 

• Ccnq>lexity. In a complex system, the class hierarchies for related classes 
can become extremely confusing, with many dozens or even hundreds of 
classes. 

• Flow of control A program written with the aid ofclass libraries is still 
responsible for tiiie flow of control (i.e^ it must control the interactions 
among all the objects created &om a particular library). The programmer has* 
to decide which &nctions to call at what times for vMch kinds of objects. 

• Duplication of effort Although class libraries allow pr ogr a mmers to use and 
reuse many small pieces of code, each piogranmier puts those pieces together 
in a different way. Two different programmers can use the same set ofclass 
libraries to write two programs that do exactly the same filing but whose 
intemal structure (i.e., design) may be quite different depending on hundreds 
of small decisions each prograpoaner makes along the way. Inevitably, 
similar pieces of code oad up doing similar things in sli^tly different ways 
and do not wo± as well together as they should 

Class libraries are very flexible. As programs grow more complex, more 
programmers are forced to reinvent basic solutions to basic problems over and over 
again. A relatively new extension of the class library concept is to have a framework 
ofclass libraries. This fifamework is more complex and consists of significant 
collections of collaborating classes that capture both the small scale pattens and 
major mechanisms that implem»it the common requirements and design in a 
spedjBc application domain. They were first developed to free appfication 
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piogrammeis from the chores involved in displaying menus, windows, dialog boxes, 
and other standard user interface elements jfor personal computers. 

Erameworics also rq)resent a change in the way programmers think about the 
5 interaction between the code th^ write and code written by others. In flie early days 
of procedural programming, the programmer called lifararies provided by the 
operating system to pedbrm c^tain tasks, but basically the program executed down 
the page fixmi start to finish, and die programmer was solely responsible &r Hhe flow 
of control. This was qypnpdate for printiiig out paycheclis, calculate 
10 mathematical table, or solving other problems with a program that executed in just 
oneway. 

The development of graphical user inter&ces began to turn this procedural 
programming ariang^ent inside out These inter&ces allow the user, rather titian 

IS program log^c, to drive the program and decide when certain actions should be 

performed. Today, most personal computer software accompUshes this by means of 
an event loop whidbi monitors the mouse, keyboard, and other sources of external 
events and calls Ac appropriate parts of the programmer's code according to actions 
that the user performs. The programmer no longer determines the order in which 

20 events occur, histead, a program is divided into separate pieces fhdi are called at 
unpredictable thnes and in an unpredictable order. By relinquishing control in this 
way to users, the developer creates a program that is much easier to use. 
Nevertheless, individual pieces of the program written by flxe developer still call 
libraries provided by the operating syst^ to accomplish certain tasks, and the 

25 programmer must still determine the flow of control within eadi piece after it's 
called by the event loop. Application code still "sits on top of* the system. 

Even event loop programs require programmers to write a lot of code that should not 
need to be written separately for ev^ application. The concept of an application 
30 framework carries the event loop concept further. Instead of dealing with all the 
nuts and bolts of constructing basic menus, windows, and dialog boxes and then 
making these filings all work togeflier, programmeis using £^plication frameworks 



-17- 

start with woridng application code and basic user interface elements in place. 
Subsequently, they build firom there by replacing some of the gen^c capabilities of 
the framework with the specific capabilities of the inteDded application. 

5 Application frameworks reduce &e total amount of code that a programmer has to 
mite fiom scratch. However, because ^ firamewojk is really a generic plication 
that displ^ windows, siqpports copy and paste, and so on, flie programmer can also 
relinquish control to a greater degree than event loop programs p^mit The 
framework code takes care of almost all event handling and flow of control, and the 
10 programmer's code is called only when ttie jframework needs it (e.g., to create or 
manipulate a proprietary data structure). 



A programmer writing a framework program not only relinquishes control to the 
user (as is also true for event loop programs), but also relinquishes &e detailed flow 
IS ofcontrol within Ae program to the fiamewoik. This approach allows Recreation 
of more conq)Iex systems 4iat work together in interesting ways, as opposed to 
isolated programs, having custom code;, being created over and ovct again for similar 
problems. 

20 Thus, as is explained above, a firamework basically is a collection of cooperating 
elates that make up a reusable design solution for a given problem domain. It 
typically includes objects &at provide default behavior (e.g.,'for menus and 
vmdows), and programmers use it by inheriting some of Aat de&ult behavior and 
oveniding other behavior so tiiat the framework calls application code at the 

25 appropriate times. 

There are three main differences between frameworks and class libraries: 
• Behavior versus protocol Class Hbraries are essentially collections of 

b^viors that you can call when you vtzrX titiose individual behaviors in your 
30 program. A framework, on the other hand, provides not only behavior but 

also the protocol or set of rules that govern the wsc)^ in which behaviors can 
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be conibiiied, including rules for what a programmer is siqpposed to provide 
versus what flie framewoik provides. 

• CaQ v^sus ovemde» a class libraiy^ the code the programmer 
instantiates objects and calls member functioiis. It's possible to 

m 

5 mstantiate and call objects in fte same way with a fiamework (i.e., to treat 

fte fiamewoik as a class lihraryX but to take full advantage of a framework's 
reusable design, a programmer typically writes code that overrides and is 
called by the fiamewoik. The fiamewoik manages Qie flow of control among 
its objects. Writing a piogram involves dividing responsibilities among the 
10 various pieces of software that are called by the fiamework ra&er than 

specii^dng how the diffoxnt pieces should work together. 

• hnplementation versus design. With class libraries, programme reuse only 
implementationSy whereas wiOi fiameworks» they reuse design. A framework 
embodies fte way a &mily of related programs or pieces of software work. It 

15 rq>resents a generic design solution that can-be adqited to a variety of 

specific problems in a given domain. For example^ a single fiamework can 
embody the way a user inter&ce woifcs, even thoujgh two difiermt user 
inter&ces created with the same fiamework might solve quite different 
intei&ce problons. 

20 

Tlius, through the development of fi:ameworks for solutions to various problems and 
programming tasks, significant reductions in the design and development effort for 
software can be achieved. A preferred embodiment of the invention utilizes 
HyperText Maikap Language (HIML) to iii^>lement documents on the latemet 

25 togeflier with & general-purpose secure communication ]ut)tocol for a transport 
medium between the client and the Newco. HTTP or other protocols could be 
readily substituted for HTML wi&out undue experimentation. Information on titiese 
products is available in T. Bemers-Lee, D. Connoly, "RFC 1866; Hypertext Markup 
Language - 2.0" (Nov. 1995); andR. Fieldm& H, Fiystyk, T. Bemm-Lee, J. Gettys 

30 and LC. Mogul, "Hypertext Transfer Protocol - HTIP/Ll : HTTP Working Group 
Internet Draft" CM^ay 2, 1996). HTML is a simple data format used to create 
hypertext documents tibuit are portable fiom one platform to another. HTML 
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documents are SGML documents with generic semantics that are appropriate for 
rq)zeseotinginfoimadonfbmamdeTangeofdcma^ HTML has been in use by 
the World-Wide Web global information initiative since 1990* HTML is an 
^plication of ISO Standard 8S79; 1986 Infonnatiou Processing Te^ct and OjESce 
Systems; Standard Generalized Madoq? Language (SGML). 

To date» Web development tools have been limited in their ability to create dynamic 
Web q>plications which span fiom client to server and interoperate vdth existing 
CQn:9>uttng resources. Until rec^tly, HTML has been the dominant technology used 
in development of Web-based solutions. However> HTML has proven to be 
inadequate in the following areas: 

• Poor performance; 

• Restricted user interface cs^abilities; 

• Can onlyproduce static Web pages; 

• Lack of intetoperability with existing applications and data; and 

• Inability to scale. 

Sun MiOT>sy5tOTi*s Java langoage solves many of flie client-side problrais by: 

• bnproving perfonnance on the client side; 

• Enabling flie creation of dynamic, real-time Web ^plications; and 

• Providing the ability to create a wide variety of user interfoce components. . 

With Java, develops can create robust User Interface (UQ components. Custom 
^vidgets" (e.g., real-time stock tickers, animated icons, etc.) can be created, and 
client-side perfonnance is improved Unlike HTML^ Java si^oits &e notion of 
client-side validation, offloading appropriate processing onto client for improved 
performance. Dynamic^ real-time Web pages can be created. Using the above- 
mentioned custom UI components, dynamic Web pageis can also be cheated. 

Sun's Java language has emerged as an industry-recognized language for 
"programming the Xntemet" Sun defines Java as: "a sinq)le, object-oriented. 
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distributed, interpreted, robust, secure^ aicObdtecture-neutial, portable, hi^- 
pedbnxiance, multitfaoreaded, dynamic, buzzword-cQmpliant, geaeral-puipose 
programniing language. Java supports progranmung for the Internet in the foim of 
plfltform-mdependent Java applets." Java applets are small, specialized applications 
5 that comply with Snn^s Java Appfication Programming Inter&ce (API) allowing 
developers to add "interactive content" to Web documents (e.g., simple animations, 
page adommentSi basic games, etc.)* ^plets execute within a Java-compatible 
browser (ag., Netscape Navigator) by copying code fiom the server to client From 
a language stand[poinl» Java's core feature set is based on C++. Sun's Java literature 
1 0 states ti^at Java is basically, "OH- with extensions fiom Objective C for more 
dynamic metibod resolution." 

Another technology ttat provides similar iunction to JAVA is provided by Mcrosoit 
and ActiveX Technologies, to give developers and Web designers wherewithal to 

15 build dynamic content for tiielhtOTiet and personal computers. ActiveX includes 
tools for devdoping animation, 3-D virtual reahty, video and other multimedia 
content Ihe tools use hitemet standards, woik on multiple platforms^ and are bemg 
supported by over 100 companies. The gror^'s building blocks are called ActiveX 
Controls, small, £ist components that enable developers to enibed parts of software 

20 in hypertext markup language (HTML) pages. ActiveX Controls work with a variety 
of programming languages including Microsoft Visual C++, Borland Delphi, 
Microsoft Visual Basic programming ^stem and, in the future, Microsoft's 
development tool for Java, code named "Jakarta." ActiveX Technologies also 
includes ActiveX Sctvct Framewodc, allowing developers to create server 

25 applications. .One of ordinary skill in the art readily recognizes that ActiveX could 
be substituted for JAVA without undue experimentation to practice the invoitiorL 

Synchronization Overview 

30 Figure 2 illustrates a flowchart delineating a method for synchronizing an event on a 
plurality of client ^^paratuses. First, in operation 200, an event is stored in m^iory 
on at least one of the client q>paratuses. hi various embodimmts, the memory may 
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take the form of an electromagnetic medimn^ or my type of optical storage device, 
i.e. CD-audio, la a piimaiy aspect of the present invention, the memoiy includes a 
digital video disc (DVD) (audio or video). Further, for reasons that will soon 
become ^aren^ fhe information includes ch^ter information associated with the 
DVD. In such embodiment where the memory is portable^ the user may be required 
to purchase tiie memory, i.e. DVD, in order to participle in a synchronized event, 
thus increasing tiie sale of DVD's. 

Jt should b e noted that the evmt need not be necessarily stored in memory on all of 
the client q^paratuses, but rather stored on one or some of the client apparatuses and 
streamed to the remaining client ^paratuses at variant rates. This may be feasibly. 
accrarqiHshed if the client apparatus(es) containing the stored event has a high- 
bandwidth coimection with the remaining climt apparatuses. For example, the client 
apparatus(es) cor^ainizig the stored event may include a serv^ tiiat has a connection 
to a plurality of televisions via a cable network, Le. WEBTV* Similar functionality 
may be achieved via a broadcast medium* The presmt inv^on is thus flexible by 
having an ability to host user events and corporative events. 

la one embodiment, the event includes a video and audio presentation such as 
movie, a concert, and/or a theatrical event. It should be noted, however, that tire 
event may included any recording capable of being played bade for entertainment, 
education, informative or oth^ similar purposes. 

In use, the client qyparatuses and a host conq>uter are adc^ted to be cormected to a 
network. Such network may include a wid^ local or any oth^ type of 
communication network. For example, a wide area netwodc such as the lutemet may 
be employed which operates using TCP/IP or IPX protocols. 

In operation 202, information is transmitted from the host coEaputesr to the 
appropriate client s^paratuses utilizing the network. This information allows for the 
shnuhaneous and synchronous playback of the event on each of flie client 
apparatuses. In one embodunmt, the information m^ also include a start time when 
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the playback of tfie event is to begin on each of tiie client ^paratuses. Further, an 
ending time maybe included when the playback of Ihe event is to end on each of the 
client ^parabises. Still yet» ^lay" conmiand in&nnation may be sent to the cfient 
£^aratuses at Ihe start time. As an option, inpnt may be received from the user, and 
5 used to altCT the playback of the evmt The host s^er, or synchronization server, 
can also control various streams of a variant rate and different hardware associated 
with fliose streams. 

Ihe present invention thus has the ability to synchronize video pl^back for one or 
1 0 multiple (thousands) users fiom one or multiple physical locations, and to 
synchronize with external video, audio and/or data streams. 

Users of the present invention are at multiple physical locations and host servers 
may also be at diff^ent locations. The pres^ invention is thus a scalable syst^ 
IS which is enable ofservicing an unlimited number of users. Since die content is 
local to the user maclunei, no hi^ network bandwidOi is required. 

History Download Capabilities 

20 Figure 3 illustrates a flowdiart delineatmg a meOiod for storing synchronization 
information for subsequent playback of an event hntially, in operation 300, an 
event is stored in memory on at least one of the client ^paratuses, as set forth 
earfiear. These client ^araluses are adq)ted to be connected to a network along 
wifli a host computer during use. 

25 

hi operation 302, infomoation is stored on the host coiiq)uter(s) for allowing the 
simultaneous playback of die event on each of the client apparatuses* In one 
embodiment, the information may include a history and data associated with the 
synduronous playback. In particular, the history may include any overlaid 
30 material(as will be described h^i^after in greater detail), any specific commands 
affecting the playback of the infbmiation, or any o&er type of general information, 
i.e. start time, end time, etc. 
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Jn op^tion 304, flie izifonnation may be downloaded utilizing the network at my 
time after the syncfaronow playback of the event Such downloaded infoimation 
may then be used for playback after fhe simultaneoas playback of the evmt. As 
5 such, the present invention has the ability to allow useis to download a history and 
data associated with a particular synchronization event and play it later. 

Overlay Synchronization 

10 Figure 4 iUustrates a flowchart scttmg forth a m^od for providing overlays during a 
synchronized event on a plurality of client ^paracuses or any other source. First, in 
operation 400, a pfanaHtyofcHcntqyparatoses are connected via a netwoik. In 
operation 402, an eveait may be simiiltaneously played h3£k on the cliesat ^paratuses 
utilizing tiie netwoxk, as set fortii earlier. 

15 

During the playback of Ihe event, visual and/or audio material mzy also be overlaid 
on the event based on input received fiom at least one of tiie cli^t apparatuses. See 
operation 404. This may be accomplished by transnutting flie overlay material from 
one of the client apparatuses to the host compute or any other server, and 
20 multicasting the same to the remaining cUent apparatuses. 

As an option, the ov^lay material may include aimotations on a display of the client 
apparatus. For example, fhe overlay material may include sketches v/inch are 
ixQ)uttedby way of a stylus-based input screen or akeyboard or &e like^ along with a 
25 voiceover izputted by way of a microphone or voice synthesizer* Sudi c^ability 
may also be quite valuable in an educational environment 

Jn one embodiment, tiie overlay material may also be displ^^ on each of the client 
apparatuses utilizing the network. This allows each of tiie users to experience the 
30 overiay in real-time during tiie simultaneous playback of the event As an option, 
tiie usCT inputtmg the overiay material may select which users may experience the 
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overlay material. The client apparatus that provided the overlay material may also 
be identified to tfie users e}cperiencmg the overlay material. 

It should be noted fiiat various bi-directional communication may be enabled fi)r 
5 allowing data to travel to and from the server* For instance, the playback of the event on 
the climt apparatuses m^ be altered in any feasible way based on input fiom a user. 

Late Synd mnTttTatioTi 

10 Figure 5 illustrates a flow diagram for delayed synchronization of an event on a 
plurality of client apparatuses. First, in operation 500, a plurality of client 
apparatuses are connected via a network and an evoit is stored in mCTiory on fte 
client apparatuses. The event is then simultaneously pl^red back on the client 
apparatuses utilizing the network, as set forth earlier. Note operation 502, 

15 

During the simultaneous playback, a request may be received from one of the cUent 
^aratuses for that paiticular to be included in the synchronized event, as set forth 
in operation 504. This request niay be recdvedafier the synchronized event has 
already begun while it is stm playing. Fur&er, the request may be submitted via a 
20 site on anetWQric,i.e, website. 

In response to the request, iafi>nnation is transmitted in operation 506 to the 
requesting cHeut s^pparatus utilizing &e netwoik. This information is adapted for 
identi^dng a location in the m^oiy wh^ the event is currently being played back. 
25 This allows the simultaneous playback of the event on the requesting client 
^aratus. 

The end users are thus able to come in at a lato: time and to be synchronized with the 
event Targeted synchronization and various filters criteria can be applied to target 
30 differrat audiences. Also language and cuttnral differences can be taken into 

account Still yet, the present inv^ition m^be adapted to address users on different 
hardware platforms (MAC, PC, set-top boxes). This maybe accomplished by 
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identi^ing tide user using a cookie, a user profile which is identijGed by way of a log 
in, or aBum Cut Area (BCA) of the disc. 

Aa exaznple setting forth details relating to identll^g DVDs will now be set fbrth. 
First; a content owner (such as studio) requests use of the BCA on their DVDs. Based 
on request, the replicator (examples include WAMO, Panasonic, Nimbus, Technicolor, 
Pioneer, Crest) adds unique BCA nmnb^ to every DVD. Adding BCA namber to each 
DVD requires a special (YAG) laser. Thismaybedieveiylast stq>inthe 
manu&ctuiing process* The BCA numbers for a specific DVD must then be entered 
into IiterActual's BCA database* hrfonnation to track includes: DVD title, i.e. *Xost in 
Space"; BCA Wxznge, i.e. 12345687890; and Shq)ping Packaging/Tracking Conlaina, 
i.e. Box 52221 to Hollywood Video. 

After tiie BCA number is added to the DVDs, the DVDs are packagin^oxed for 
distribution to either the Distributor or the Retailer. It should be noted that many 
companies take multrple forms, so the replicator and distributor may be one in flie 
same* Also, some retailers are large/important raough to get sfaq>ment5 directly 
firom replicator. The way in which the DVDs are packaging/shipped is 
important because one must track the BCA numbers to actual shaping containers 
(box, etc). Therefore tracking information must also be added to the BCA database. 

If packaged DVDs are th^ sent to distributor, the distributor also has mechanisms, 
ie. scarmers, input device^ and monitoring devices, in place for tracking based on 
ttieir distribution. For example, Dehnce may receive a '^ack^e" of 100,000 copies 
of 'Xost in Space." However, fte distributor ships 10,000 to Retailer A and 5,000 to 
Retailer B. Hie distributor should be able to ^put" retailer A and B's distribution 
information into the system. Ideally, this becomes a seamless/automated process. 

Once the DVDs reach the retailer (either iStom the replicator or distributor), then 
DVDs may be further divided and distdbuted to local stores/outlets. la such a 
situation, &e retailer should be able to automatically *track*' distribution of these 
DVDs through to their stores. Over time, all three entitities (replicator, distributcnr. 
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and retailer) are ^le to add tracking iisfozmation to BCA database. Due to 
complexity and dependencies on existing business systenos, the retail tracking 
concept ^mll be rolled out in phases: replicator first most likely with key retail 
accounts. The distributors will be brought in. Retailers will tiien begin to embrace 
5 tiie ability to track based on local ouflet/store* 

By the fixcegoing design, easy deployment is fiius afforded and minixaal hardware is 
required to allow ttie synchronization of content without significant capital 
investments and with a very e£Eicient control mecfaanisnt The content delivery does 
10 not rely on Mgh network bandwidth and is indq)endentftoni&e synchronization . 

Mem^ Server Application Program haterj^e (ISAPQ extensions wiU be used on the 
server. ISAPI extensions provide a mechanism to maintain a tenq>oraiy or 
psmanent connection with &e users. These coimections aUow (he Synchronization 
15 Server to process request and to s^flie appropriate DVD cominands. The 

pennanent connections are known as ^'Keep A&ve" coimections. IS API extension 
can also b e used as an HTTP interface to a more traditional server, witfi all data 
returned as text 

20 On the client side the approach is to use^ but not limited to Java 1 . 1 applets, to 

initiate event start-15) for flie Synchronization serv^. The advantage of iising Java 
1.1 applets is to achieve platform independence for existmg and jfuture Java-en^led 
devices. JavaScript will be used to provide user inter&ce navigation by '"mapping* 
the applet 

25 

An ESAPI Ohtemet Server Application Program hiter&ce) is a s^ of Windows 
program calls that let one write a Web server plication tfiat will run &ster than a 
Common Gateway hiterface (CGI) ^plicatioju A disadvantage of a CGI a^Ucation 
(or ^'executable filei»" as it is sometimes called) id fliat each thne it is run, it runs as a 
30 separate process with its own address space» resulting in extra instructions that have 
to be performed, especially if many instances of it are running on behalf of users. 
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Using ISAPJ^ you <xreate a Dynamic Link Lihraxy (DLL) application file that can run 
as part of ike Hypertext Transport Protocol (EnTP) ^lication*s process and address 
space. The DLL ffles are loaded into the computer when HTTP is started and r 
fbsxe as long as they are needed; they dont have to be located and read into storage 
as freqaently as a CGI application. 

Existing CGI applicatioBS can be converted into IS API q)pHcatioxx DLLs without 
having to rewrite &eir logic. However, they do need to be written to be fhread-safe 
so that a smgle instance of the DLL can serve midfiple users. 

A special kmd of SAPI DLL is called an ISAPI filter, which can be designated to 
receive cojolrol for every HTTP request One can create an ISAPIiSlter for 
encryption or decryption, for logging, for request screening, or for other purposes. 

One can write IS API server extension DLLs (IS As) that can be loaded and called by 
the HTTP server. Users can fill out forms and click a submit button to send data to a 
Wdb server and invoke an ISA, which can process tfie information to provide custom 
content or store it in a database. Web server extensions can use information in a 
database to build Web pages dynamically, and then send them to the client 
con^mters to be displayed. An application can add other custom functiona£ity and 
provide data to ^e client usingHTTP andHTML. 

One can write an ISAPI filter. Thefitt^isalso aDLLthatnmsonanlSAPI- 
enabled HTTP server* The filter registers for notificalion of events such as loggio^ 
on or URL mapping. When the selected events occur, the filt^ is called, and one 
can monitor and change the data (on its way 6om the server to the client or vice 
versa). ISAPI filters can be used to provide custom encryption or conqpression 
schemes, or additional auCbentication me&ods. 

Both server extensions and filters run in the process space of &e Web s^er, 
providing an efficient way to ^end the server's c^abiliiies. 
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-28- 



The various functioixal conqjonents of fho soitv/are associated with the preseat 
inveatioii will now be set fortfa* Such components mchtde a Java/JavaScript 
Component, Syncfaromzer Coniponent, LayerDupI Component, Business Layer 
5 Component, Configuration Manage Component, and DBComiect Component. 

Java/JavaScript Component 

Fi gmre 6 illustrates a flow diagram for providing informatioxi on a syndbronized 
10 event on a plurality of client apparatuses in accordance with one embodiment of the 
present inv^tioii. Fiis^ in operation 600» a plurality of client apparatuses are 
connected via a netwodc, as set forfh earlier. Next, an application program is 
embedded on a site on the network in operation 602. Such qjplicadon program may 
take the form of a JAVA appi et, and the site may include a website on the Ihtemet 
15 . • 

In use, infonnation is requested from a s^er on the network utilizing the 
application program. See operation 604. Such infonnation relates to an event to be 
played back simultaneously on the client ^aratuses and may include general 
infbrmatiGn such as a start and stop time of the event, or more specific in&imation 
20 about the event itself. 

In response to such request, a script is received for displaybg fiie information. Note 
operation 606. The Gcrq)tmay take any form mA as Perl, REXX (on IBM 
mainframes), and TciyHc, and preferably includes a JAVAscript 

25 

In one embodiment of the present invention, the JAVA ^plet may be further 
adapted to send a request to retrieve command information from the serv^ for use 
with a playback device of one of the client sqpparatuses. The commands may be 
adapted to playback the event on the playback device simultaneous witii the 
30 playback ofthe event on &e remaining client apparatuses. Furdi^*, the commands 
may include a start time wbsa the playback of flie event is to begin on each of the 
. client apparatuses. 
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The JAVA e^lets and JAVAscript are vsed to communicate with the pla>6ack device 
of the clieat apparatuses* h one embodiment, &e playback device inchides a 
PCEriendly TM video player mannfectured by Ihteractual ®- 

The Java q>plet is embedded within a web page and uses HTTP protocol to 
communicate to the syachionization sescve^. The ^plet could request event 
infonnation fiom the server, and display it to the user via JavaScdqpt The Eqpplet 
could also send a "BroadcastVideoEyenf'TGquQst to retrieve DVD commands Ibat 
can be passed to the video componeni; as set forth hereinabove. 

Synchronizer Component 

Figure 7 illustrates a method for creatmg a synchronizer object in order to pla^ack 
an event simultaneously on a plurality of client ^paiatuses. The synctnonizer object 
is portion of the software that actually implements Ifae synchronization procedure. 
First, in op^tion 700, a request is received utilizmg a network for viewing an event 
NtacXj the request is queued in memory in operation 702. 

hi response to the request, in operation 704, an object is created which is adapted to 
playback the event on a client apparatus simultaneous with the playback of the event 
on l3ie remaining chent apparatuses upon the receipt of an activation signal. As an 
option, the activation signal may be provided using a clock of the chent apparatus, or 
located at a different location, i.e. server. To accomplish this, the object identifies a 
start time whrai the playi^ack of flie event is to begin on each of die client 
apparatuses. 

In operation 706, the object is sent to one of the clioit ^paratoses utilizing the 
netwoik for bdng stored therdn. hi accordance with a primary aspect of the present 
invention, fte object may be ad^ted to playback tiie event which is stored in 
m^oiy of fte cHent ^paratus. This may be accomplished by activating a digital 
video disc (DVD) playar. 
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Jn summaiy, whea the Synchromzer component receives a "BroadcastVideoEvenf* 
fiom die ^let, it tiben places the request in the ttuead queue for processing. To 
process a request, the thread creates a "call back^ object, if one does not exist for 
5 this event The thread then adds the request to the "call back"" object queue. This 
"call back*' object will be invoked whea it is time to play the DVD. The 
Synduoniz^ component creates a Call Back COM object, LayerSink, The 
Synchronizer component is also responsible for creating the LayerFactory interface 
which will be set forth hereinafier in greats detail 

10 

Laverhnpl Component 

Figure 8 illustrates a flowchart for affording a scheduler object adapted to facilitate 
the pl^ack of an event simultaneously on a plurality of networked client 
15 apparatuses. The present method ensures that critical information is tracked dming 
the synchronizadon of die ev^t Such critical information not only ensures prop^ 
synchronization, but also enables vaiions peripheral features. 

First, in operation 800, various values are detennined mchiding a current time, a 
20 start time when an event is to start, and a stop time when the event is to end . 

Thereafter, a lengdi of the event is calculated based on the start time and the stop 
time in operation 802. As aoi option^ the current time is determined by querying a 
clock of one of ttie client ^paratuses. 

25 If any portion of the length of the event takes place during a predetermined direshold 
period, a conmiand is stored in m^ory in operation 804. The command may be 
ad^ted to automatically begin playmg back the event at the start time, hi one 
embodiment, the thre^ld period includes the time die users can be queued before 
the event As an option, charter infomiation may be stored in the memory if any 

30 portion of the leqgdi of the event takes place during the predetsmined tibresbold 
period. This allows the command to automatically begin playing back the event at a 
predetermined chapter* 
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la operation 806, a loop is created at the stot time dming which a l^sed time of the 
event is tracked* This infoanationxmy be used for vadous tracks 
decide when to issue conunands to ttie usot. In another embodiment & second loop 
5 may be created upon the beginning of a chapter during which information on a next 
chapter is retrieved. 

The "call bac]^' object (LayerSink) is thus responsible for creating and 
coinmunicattngwiQitheZ^Q/er/mi^/componesiL The£ayer7iKj7/conqK)nentact5asa 
10 scheduler, determining when to issue commands to the us«^. 

Xoy^^'J^/ will issue dififerentDVD commands, based onfhe type of decoder flie 
user has in their PC. Lqyerlmpl will differentiate betwera the decoders by using the 
decoder information submitted fiom &e client The Layerlmpl will pass the correct 
1 5 DVD command to the client, based on the decoder's cq)abilitie$. For example, if 
the decoder does not support ttie HmePlay event, thm &e server may send a 
ChapterPlay event and wait appropriately. 

The following is an enumerated summary of the stq>s the component nses to 
20 deteonine when the users will receive the DVD commands: 

1. Retrieves the current time, and the time the event starts and ends. 

2. Calculates the length of the event 

3. If the event is within a tibreshold period (ie» die time users can be queued before 
25 the eveat),&en store the first DVD conmiand in memory. Also, store the Cb^ter 

information in memory. 

4. Create a loojp that processes request until the event has conxpleted. 
S* In tiie loop, calculate the lapsed time of the event 

6. la the loop, retrieve the next chapter in&rmatioiL 
30 7. Create another loop that will loop until time for the next cheater to be played. 

8. When the next chapter is ready to pl^, send the command that was retrieved &om 
the Chapter table. 
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Business Layer Compoiient 

Figuie 9 is a flowchart delineating a method for idcntij^g aplurality of events 

# 

which are played hack simultaneoiisly on a plnrali^ of networked client ^aiatuses. 
This features is important since a host server may be synchronizing more than one 
event at once, or during overlapping times. Such ev^ts must therefore be 
distinguished. 

First, in operation 900, a plurality of events are stored in memory on a plurality of 
client apparatuses. Each of flie events is assigaed a unique identifier whidi is stored 
in&ememoiy. 

In opeiation 902, the cHent apparatuses are adapted to be coupled to a host conq>uter 
via a network, as set forth hereinabove. la op^tion 904, the identifier of the ev^ 
yAdch is stored in &e memory of the client q)paratuses is ften retrieved utilizing the 
networic. Such identifier is subsequently compared with an identifi^ of a scheduled 
even^ as set forth in operation 906. Kthe comparison rendois a match, the playback 
of the event is begun on the appropriate client apparatuses. Note op^tion 908. 

CbusinessLayer thus diifeimtiates events by the disk and location ids, uploaded by 
the client to guarantee backwards conipatibility. As set forth earlier, late arrivals can 
always re-sync with the evrat, 

r!nnfip[iira tion Manager Component 

Figure 10 shows a flowchart delineatiug a technique for identi^dng playback devices 
of a plurality of client apparatuses which are networked to simultaneonsly playback 
an event The present technique is important since the playback devices of the 
various client apparatuses may differ in make and model Thxis, different commands 
are required therefor. 
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In operation 1000, a type of fhe playback d&vices of the client apparatuses is jSist 
identified. Such *1ype" may refer to a make, model, or any other distinguisbing . 
characteristic ofthe particular playback devices. A command associated wilh the 
identified type of the playback device is then looked up in a look-ixp table. Note 
5 operation 1002. Such table may be located at the host server, or at aiqr other location 
suchi as the client apparatuses. 

Thereafter, in operation 1004, the command is sent to the correspondipg clioit 
^paxatus for beginning the playback of the event simultaneous^ with the pl^ack 
10 of the event on each of the remaining client apparatus^. 

This conqjonoit is thus responsible for identifying what type of rejEerence pl^er is 
hosting the event The reference player can be the database, vMch contains tbie 
DVD commands or areal time player. When the initial DVD is conunand is 
15 requested, the "Syncfaronizef" table is queried &r the host type. From that point 
forward, the scheduler would know &am whom to recdve data 

DBCoimect Component 

20 This component is responsible for corumunicating with the Synchronizer tables, and 
for providiiig access methods for the retrieved data. All interaction from the tabl^ is 
on a read-only basis. The Lqyerlmpl component communicates with this component 
to retrieve DVD commands and evoit infomiatioxL 

25 Even though current inQ)lementation may be based on a Microsoft platform, hard 
dependencies on Microsoft or any other 3rd-party development tools maybe 
avoided. To address such issues, &e following considerations may be made 
throughout the code: 

30 MFC specific code may be avoided, histead, STL may be used. ATL and/or MFC 
code may be encapsulated into separate classes and portioned &om the rest of the 
code. Qass implementations may use aggregation pattern to delegate business logic 
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to die portable classes. Database connection classes maybe separated and the 
communication protocol may be sq}arated vnih respect to portability to Oracle and 
other platforms* 

Figures 11 and 12 illustrate the order of events among the various components of the 
present inventloxL In particular. Figure 11 illustrates the manner in vMch a layi^ 
&ctory is created. As shown, an event is first diecked in a database server after 
which a business layer is created in a WEB server in a manner set forfli hereinabove. 
The foregoing components are then created. Figure 1 2 illusfrafes the mann^ in 
which user requests are processed As shown, comraunication is afforded wi& the 
video player on the client machine by means of JAVAscript and JAVA sqpplets. The 
WEB server, m turn, conununicates DVD commaads to the video play^ via tiie 
JAVA applets, and also inter&ces the database server via flie various components 
thereof whidi were set forth hereinabove. 

Alternate RrnhnfjimRntg 

To support iiiture enhancements, further components may be included witii ext^dibility 
as the major objective. Various future enhancements of the product and how they will 
be addressed will now be set forth. 

Hosted Real Time Players 

While spirals may retrieve pre-xecorded DVD commands fiom the database, 
altOTiateqrirals may siq^ort a consumer as a host The architecture may also 
support plug-in components. Alternate spirals may support the RealUmeConnector 
component, which accepts host user request and forwards them to the clients. The 
instant architecture supports the DBCormector which accepts events fiom the 
database. 

Keep Alive Connections 
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Clients may maintain connections throughout the event. This allows the host to seaid 
a various number of commands to the client of the event Al&ough the spiral 
disconnects users once a PLAY command has been issued, the Synchronizer class 
(which will be set forth later) adds each connection to a Thread PooL This pool of 
connections can be left open during tiie life of flie event 

Logging Participants 

Each request may be logged into tibe database to provide a reference for fte future. 

DVD Positioning 

As an option, connections may be pooled to allow the synchronization server to 
direct consumer's machines to the certain locations throu^out the enthe event 

Synchronization events in alternate spirals may be defbied as a combination of play 
fiom location event and the actual evmt This way, one describes each event in &e 
unambiguous way on the client side and synchronizes it with the sorver. For 
example, a situation may be considered where one fest forwards aftor a movie is 
played for IS min and th^eafter plays the scene in the movie. In such situation, one 
has to submit the infbnnation to the client player, indicating that it (player) has to 
start time play fiom 15 min into the movie and fast-forward to the certain location. 
A better way would be to analyze what is the next event after fest forwarding 
occurred and perform a combination for the play from location and next event This 
design wouId*require significant changes to the client infiastructure, including video 
object^ remoteageni and provider and should be taken into consideration in any 
attemate client desi^. 

Classes/Component Diagrams 

Hgures 13-16 illustrate various class/component diagrams, hi particular, Figures 13- 
16 illustrate a Synchronizer Class Diagram 1300, Layerhnpl Class Diagram 1400, 



Biisiness Layer Class Diagram 1500, and DBComiect Class Diagram 1600, 
respectively. 

Sequence Diagrams 

5 

Figure 17 illustrates a logical sequence diagram 1700. As shown, when the server 
receives a user request, it analyzes the authentication information of the request 
(date/time, disc id, user id, and BCA numb^) and the appropriate synchronization 
event stored in the database. Ihe database contains an event start threshold value 
10 measured in milliseconds. This threshold defines the amount of time prior to an 
event fliat a consumer is ehgible to "coimecf ' for the start of the event 

]ff flie date/time of the user request lies within the event start threshold, the user is put 
into wait queue and receive the appropriate, data when the time elapses. Note stq>5 
15 1,23»S,6,7 of the Logical Sequence diagram. Otherwise, a message is sent 

infonning flie user when the event will occur. Note stqp 4 of the Logical Sequence, 
diagram. 

Server side collaboration diagram 

20 

Figure 18 iltustrates a logical sequence diagram 1800 that shows server side 
collaboration. As shown, server ISAPI extension receives a BroadcastVideoEvents 
request calls lA^usinessServer via BeginProcess, to r^eve configuration 
information. Configuration mforination contains a playback connector. Pl^ack 
25 connector ideptifies whether the server will have to communicate with a ref^ence 
pl^rer or will it perform playback 6om the database. 

At step 6, ISAPI extension will call JAJSusinessServer CompareTime method and 
based on the results will send to the user a predefined web page indicating to retry 
30 lator or return control to £he web server, notifying it (web server) to keqp the 

connection open. At this point connection is pooled and will be processed by the 
IA_BminessServer at a time of the event 
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CKent Collaboration Diagram 

Figure 19 illustrates a logical sequeace diagram 1900 showing cli^ side 
5 collaboration ia accordance with one embodimmt of the present invention. 

Classes/biteifaces Definition 

Definitions of one embodiment of the various classes associated with the software which 
10 implements the present invention will now be set forth. 

Class Appletl 

Purpose: 

15 

This is the class that implements the applet The browser will use it to bootstrap our 
applet 

Responsibilities: 

20 

■ Request a BroadCastVideo event and to gather event status infbnnalion. 
Collaborations: 
25 BroadCastEvent, CITIEnciypt 

Base doss and implemented interfaces: 
JavaxApplet 

30 

Public interface: 
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getChapter Returns the cmxent chq)t^ the reference player is playing. 
Return type: String 
Parameters: void 
Fre-conditiom: None. 
Post-conditions: None. 

getTitlelnfo Returns the current title the reference player is playing 
Return type: String 
Parameter void 
Pre-conditions: None. 
Post-conditions: None. 

gefStartTfane Returns tiie time the event is scheduled to start 

<SS:MMfflia)DaVIM:YYYYi> 

Return type: String 

Parameters: void 

Pre-conditions: None. 

Post-conditions: None. 

getStartTimeSec Returns fte time the event starts in seconds. 
Return type: String 
Parametears: void 
Pre-conditions: None. 
Post-conditions: None. 

getStartTimeMinRetums the time the event starts in mmutes. 
Return type: String 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 



getStarlTfmeHrRetuins the time the event starts in Hours. 
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Retumtype: String 
Farametets: void 
Pre-cooiditioiis: None. 
Post-conditions: None. 

GefSfBrtTimeDay Retums the time the event starts in days. 
Return type: String 
Parameters: void 
Pre-conditions: None. 
Post-conditions: Nona 

GetStarfTfineMjifli Returos Hlg time the ev^ starts in months. 
Return type: String 
Paraineters: void 
Pre-conditions: None. 
Post-conditions: None. 

GetStarfTimeYr Returns the time the event starts in year. 
Return type: String 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 

GefLenOIEhrent Retums the length of tiie event 
Retomtype: * String 
Parameters: void 
Preconditions: None. 
Post-conditions: None. 

GetExpiredTime: Returns l^se time of &e event 
Retomtype: String 
Parameters: void 
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Pre*conditions: None. 
Post-conditiQiis: None. 

getServerllme: Returns the servers cuirent time <SS',MM:HH:DD:MM:YYYY>. 
Return type: Strfng 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 

getServeiTimeSec: Returns the serv^ current in seconds. 
Return type: String 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 

gefServeiTimeMin: Returns the servers current in minutes. 
Retum type: String 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 

getServerTtmeHr: Returns the servers current in hours. 
Return type: String 
Parameters: void 
Pre-conditions: None. 
Post*-conditions: NoneL 

getServerTimeDay: Returns the servers current in day. 
Retum type: String 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 
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getServeiTimeBlnth: Returns &e servers cuirmt in inpnfh. 
Retamtype: String 
Parameters: void 
Pre-conditions: Nona 
Post-conditions: None. 

getServerTimeYn Returns tiie servers cuirent in year. 
Return type: String 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 

starfProc: Calls the BAPIs "Se:va:Irifo'*meaod 
Return type: void 

Paramet^: String disk id. String location id 
Pre-conditions: None. 
Post-conditions: None. 

msgEvent: Calls BroadCastBvent applet 
Return type: void 
Paramet^: void 
Pre-conditions: None. 
Post-conditions: None. 

Class BrpadCasflBvent 

Purpose: 

This is die class diat invokes the Synchronizer. 
RespoTtsibilities: 
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■ Sets the JavaScript vndi the command returned fiom the server. 
CoUaboraUons: 

5 

CmEnciypt 

Base doss and implemented interfaces: 
10 JavaThread 

Qass CDBComiect 
Purpose: 

15 

. This is the class provides a pub&c inter&ce for conqponeDts to leqaest infonnation 
fiom the DB tables. 

Responsibilities: 

20 

■ Opens the database and Synchronizer, ChapterJDisk tables* 

■ Queri^ the Synchronizer by the specified disk id and location id. 

■ Queries the Chapt9_I>isk by disk id 

■ Provides fhe ncTct chapter that is scheduled to play. 

25 ■ Queri ^ the DecqderjCq>abilities table to detemune if the requested player is 
time or chapter play. 

Collaborations: 



30 DBSyncSet 

DBRjeferenceSet 
CDBCh^terSet 
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CDecodetCapabilities 

Base class and implemented interfaces: 

JPtd^lic interface: 

Get_NextChapten Retoms the next chapter to play. 
Return type: String 

Parameters: long time, long title, BSTR Ch^ter 
Pie-conditions: None. 
Post-conditions: None, 

chkEvent: Chedcs if an event is scheduled for fbe disk and location id 
Return type: String 

Parameters: long time, long titles BSTR Chapter 
Pre-conditions: None. 
Post-conditions: None. 

getJmttialDVDCoimiiand: Retoms the first DVD command to play. 
Return type: String 
Parameters: BSTR& 
Pre-conditions: None. 
Post-conditions: None. 

getjaextDVDCoDunand: Returns the next DVD command to play. 
Return type: String 
Parameters: BSTR & 
Pre-conditions: None. 
Post-conditions: None. 



decoderArray : Returns an array of decoder types. 
Return type: String 



Parameters: long * *, long ** 
Pre-conditioiis: None. 
Post-conditions: None. 

Class CGConfigMertopl 



Purpose: 

This is the class provides a public inter&ce for components to detennine the type of 
leference player hosting the event 

Responsibilities: 

' Opens the database and Synchronizer, GiapterJDisk tables. 

" Queries the SyncliiDiiizer by the specified disk id and location id 

• Stores the reference play& type. 

Collaborations: 



CConfieMgrRecSet 



Base class and implemented interfaces: 

Public interface: 

getJhostType: R^onos the referraice player host type. 
Return type: String 
Parameters: short 
Pie-conditions: None. 
Post-conditions: None. 



Class threadPimctor 
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Purpose: 

This class provides a threading model that classes can use to deacive, 
RespOTtsibilities: 

■ Calls the CreateBvent function, which opens a named or unnamed event 
ohjec. 

■ CaUs _begxnfliread, which czeates a ffarcad begins execution of a routine at 
start_addiess. The routine at startjaddiess must use the cdecl calling 
convention and should hove no retam valua When the thread returns fnom 
that routine^ it is terminated automatical^. 

■ Calls the WaitPorSingleObject function, which checks the cuir^ state of the 
specified object If the objects state is nonsigoaled, the calling thread enters 
an efiSci^ wait state. 

■ Calls the ResetEv^t function, which sets the state of the specified event 
object to nonsignaled. 

■ The state of an event object remains nonsigaaled until it is explicitly set to 
signaled by the SetEvait or PulseEvent function. 

Collaborations: 

CConfifiMctRecSet 

Base class and implemented interfaces: 

Public interface: 

start: Starts tiie thread 
Return type: void 
Parameters: void 



\ } 
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Pre-conditioiis; None. 
Post-conditions: None. 

stop: Stops liie thread. Calls CloseHandle for the fliread and event 
Return type: void 
ParametCT: void 
Pre^ndidons: None. 
Post-conditions: None. 

Class isapithread 

Pwpose: 
This creates an ISAPI thread. 

AespoitsibiUties: 

■ Adds a request to a vector. 

■ Creates the snik object 

■ Stores the request into sink object, 

" Sends the time information to JavaScript 

Collaborations: 

LayerSink 
factorySink 

Base doss and implemented interfaces: 

threadFunctor 

Public interface: 



T 
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addrequest: Adds the request to its vector. 
Return type: void 
Parameters: void 
5 Pre-conditioiis: None. 
Post-conditions: None. 

geiBLayerlnfo: Responsible for getting infoimation about the event. 
Return type: void 
10 Parameters: std:stnng&}Std::string&, ChttpServerContext^ 
Pie-conditions: None. 
Post-conditions: None. 

Class fectorvSink 

15 

Purpose: 

Manages the layerSink and businessLayeiProp objects. 
20 Responsibilities: 

■ Stores a layerSink object 

■ RetuEDS the "businesssLayetProp" <Business Layer PrDperties> 

■ Creates the "businessLay^Prop" <Business Layer stnicture> 

25 

Collaborations: 

LayerSink 
bnsinessLayeiiProp 

30 

Base class and implemented Interfaces: 
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Public interface: 



construct: Stor^ a layerSink object. 
Return type: void 
Parameters: void 



Pre-conditions: 



None. 



Post-conditions: None. 

notifyCreatcLayer: Responsible for ra^eating a *1)usiDessLayerProp^ 
Return type: void 

Parameters: BSTR, BSTR, DATE, DATE, LONG 



nnRsTftyfirMtiV 
Purpose: 

layerSink represents a sink tntei&ce and stores a queue of requests. It creates 
coimection point object 

This call back object, allows asynchronously processing. 
Responsibilities: 

" Acts as the client sink object 

■ Sends the r^ults to fheuso: 

" Creates the "BusinessLayer" and makes it a connection point object 

" Closes the users connection. 

■ Creates a Factory interface by calling ''createFactoiy". 

■ Creates a connection point for the factory. 

■ Stores the layerSitik in the FactorySink object 



Preconditions: 



None» 



Post-conditions: 



None. 
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■ CSreates a connection point (call back) by calling AtlAdvise, betv^era the 
connection point container and the client sink object Ibis allows the client 
to receive events. 

. ■ Calls flie connectable objects "getServerLayer". This method fires an evrart to 
5 the clients sink object 

■ Create a business hyer, 

" Store the request in its vector. 

■ Release the Sink Object (client) 

■ Calls AtlUnadvise to tenninates &e ability of the client to receive events. 

10 

Collaborations: 

Base class and implemented interfaces: 

15 Public interface: 

constrnct: Creates a connection point 
Return type: void 
Parameters: void 
20 Pre-conditions: None. 
Post-conditions: None. 

addRequest: Adds the request to its vector. 
Return type: void 
25 Parameteis: . BSTR, BSTR, DATE, DATE, LONG 
Pre-conditions: None. 
Post-conditions: None. 

createBusinessLayer: Creates a business layer. Create the connection point . 
30 Return type: void 

Parameteis: businessLayerProp & 
Pre-conditions: None. 
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Post-conditions: None. 

updatetime: This call back iunctioii traoslates (he time and sends the command to 
theuser. 
5 Return type: void 
Paiameteis: longjong 
Pre-conditions: None. 
Post-conditions: None. 

10 Class CBnsinessLaver 

Purpose: 

Creates a layerthread object This object is responsible for providing access mefliods, 
IS ^ch provide event infonnation. 



Responsibilities: 

" The "Syncbionizers'^ createBusinessLayer method creates a cla^ object &om 
20 the "BBusinessLayer" ioterfece. <nie class object is part of the Layedmpl 

projecO 

• The BusinesLajras class object <mjilayer> calls its "fiiitialize" mefliod, 
<Note: m_ilayer is the connection point object It identifies tihie "Sink 
Merfece" 

25 ■ Bth^ calls the "hiitialize'' method oftfae connection point 

■ The 'Initialize" method then calls the "ChkValidEvent" method, v^ch then 
creates a layerthread object 



Collaborations: 

30 

CBusinessLayer 
layerthread 
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Base class and implemented interfaces: 
Public inteiface: 

Initialize: Calls "GhkValidEveQr* method wluch kicks of a layer tbiead 
Return type: void 
Parameters: void 
Fr^conditioBs: None. 
Post-conditions: None. 

Class laVBithread 

Purpose: 

This object acts as a scheduler, processing request fiom its queue. 

Responsibilities: 

" Send DVD commands to the user. 
■ "Syncs" up late comers to the events. 

Collaborations: 

CBusinessLayer 
CDBConnect 

Base class and implemented interfaces: 

Public interface: 

startThread: Processes requests from the queue 
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Return type: void 
Parameters: void 
Pre^ndifioiis: None. 
Post-conditioiis: None. 

5 

Class CXaverFactorv 
Purpose: 

1 0 This object manages businesslay^ objects. Business layer objects conunnnicate vn&x 
tbe reference player and notify the user ^ch DVD command to pl^. 

Responsibilities: 

15 ■ Send DVD commaads to file user. 

■ *'Syncs" 15) late comers to the events. 

* This object Lnplements the IID_LayerFactory inter&ce. 

■ This COM object is ihe servers Connectable Point object 

■ This sender object supports connections to sink interfaces. Tbese sink 
20 interfaces reside on the client side and are equivalent to tbe *^call back" 

functions in Windows. 

Collaborations: 

25 CBusinessLayer 
CDBConnect 

Base class and implemented interfaces: 



30 Public interface: 
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getServerLayer : Tires" an eveat to create a business layer with the properties 

retrieved from the pipe object 

Return type: void 

Parameters: void 

Pre-conditioiis: None. 

Post-conditions: None. 

pnt_setJaycK call the "GLayerFactoiylinpr addQ me&od. Supplying the 
"businesslayer" object 

This will added to shared memoiy queue and written to a file. 
Return type: void 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 

BInaiConstruct: Calls flie "OLayerFactorylmpl" FinalConstruct COM class object 
Return type: void 
Parameters: void 
Pre-conditions: None. 
Post-conditions: None. 

Al&ough only a few embodiments of the present invention have been described in 
detail herein, it should be understood tliat flie present invention may be embodied in 
many other specific forms without dq>arting fiom the spirit or scope of the 
invention. Therefore, &e pres^ examples and embodiments are to be considered as 
illustrative and not lestrictive, and the invention is not to be limited to flte details 
given herein, but maybe modified within the scope of the £^ended claims. 
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CLAIMS 

What is claimed is: 



1 1, AmetfaodforsynchiomzinganeveatonapIuiaHtyofcUentq^ 

2 comprising the steps of: 

3 (a) comecting a plnralify of client q>paiatnses via a netwoik; 

4 (b) embedding an ^plication program on a site on the network; 

5 (c) requestmginfoiniationfix>m a server on the network utilizing fheappH^^ 

6 program^ wherein the infimnation relates to an event to be played back 

7 sixmiltaneonsly on the client apparatuses; and 

8 (S) receiving a script for displaying &e informatton. 

1 2. A me&od as recited in claim 1, wherein the plication program is fiir&CT 

2 adapted to send a request to retrieve conmiands &om Qie server fixr nse with a 

3 playback device of one of the cHent apparatuses. 

1 3. A method as recited in claim 2, wherein the playback device includes a 

2 digital video disc (DVD) player. 

14. A method as recited in claim 2, wherein the cormnands are ad^ted to 

2 playback the event on the playback device simultaneous with the playback of 

3 the event on fte rmiatning client apparatuses. 

1 5. A me&od as recited in claim 2, wherein the command includes a start time 

2 when the playback of the event is to begin on each of the client ^aratuses. 

16. A method as recited in claim 1, wherein application program is a JAVA 

2 applet and the script is JAVAscripL 



1 
2 



7. 



A computer program embodied on a computer readable medium for 
synchronizing an event on a plurality of client apparatuses, conq>rising: 
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3 (a) a code segment for connecting a plurality of client apparatuses via a network; 

4 (b) acodesegmeiitforeDabeddingan^pUcationprogranionadteon tb^ 

5 network; 

6 (c) a code segment for requesting information fiom a server on the network 

7 utilizing the plication program, i^erein flie information relates to an event 

8 to be played back simnltaneously on the cHent apparatuses; and 

9 (d) a code segment for receiving a script for di&playdng the irifoimation. 

18, A computer program as recited in claim 7, whereni the q^lication program 

2 is farther ad^ted to send a request to retrieve connnands fiom the searvef for 

3 use with a playback device of one of the client ^aratoses. 

19, A computer program as recited in claim 8, wherein fhe playback device 
2 includes a digital video disc (DVD) player. 

1 10. A compiiter program as redted in claim 8» wherein the coinman 

2 adapted to playback the event on the playback device simultaneous with (he 

3 playback of the event on the rmaining client apparatuses. 

1 1 1 - A computer program as recited in claim 8, wherein the conunand includes a 

2 start time when tfie playback of the event is to begm on each of the client 

3 sQ>paratuses. 

1 12. A computer program as recited in claim 7, wherein plication program is a 

2 JAVA ^let and tfie script is JAVAscript 

1 13. A system for synchronizing an event on a plurality of chmt apparatuses, 

2 comprising: 

3 (a) logic for coimecting a phirality of dirat apparatuses via a network; 

4 (b) logic for embedding an plication program on a site on the network; 
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5 (c) logic for requesdng mfoimation fiom a sorer on the network utilizing fhe 

6 application program, wherein the information relates to an event to be played 

7 back simultaneously on the client ^aratuses; and 

8 (d) logic for receiving a script for displaying the infomation. 

1 14. A system as recited in claim 13, wherein tfie application program is finQier 

2 adsptdd to send aiequest to retrieve commands fiom the server for use with a 

3 playback device of one of fhe client appazdtases, 

1 IS. A system as recited in claim 14, wb^in the playback device inchides a 

2 digital video disc (DVD) player. 

1 16. A system as recited in claim 14, wherein the commands are adapted to 

2 playback the event on fhe playback device simultaneous with the playback of 

3 the event on fhe rranaining client apparatuses. 

1 17. A system as ledted in claim 14, wh^pein the command includes a start to 

2 when the playback of the event is to begin on each of fhe client apparatuses. 

1 (a) 18. A system as recited in claim 13, wherein application program is a 

2 JAVA ^plet and the script is JAVAscript. 



-57- 



SYSTEIM^ METHOD AND ARUOUB OF MANUFACTURE FOR A 
JAVA/JAVASCRIPT COMPONENT IN A MULTIMEDIA 
SYNCHRONIZATION FRAMEWORK 

ABSTRACT 

A system, method and aiticle of manufacture are provided for synchronizing an 
event on a plurality of client ^aratuses. Firs^ a plurality of client ^paratoses are 
connected via a netwoik* Next, an application program is embedded on a site on the 
network* In use, information is requested fiom a server on the network utilizing the 
plication program. Sudi information relates to an event to be played back 
simultaneously on the client ^paratuses. la response to such request, a script is 
received for displ^ong the information. 
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TRANSMrmNG INFORMATION FROMTHE HOST COMPUTER TO THE CUaiT 
APPARaSwK mSo TO^^ FOR ALLOWING THE SIMULTANEOUS PLAYBACK 
'^'^™^^ i^ EVBrr ON EACH OFTHECUENT APPARATUSES 
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Figure 2 



PROVIDING AN EVENT STORED IN MEMORY ON A PUURAinY OF CUE WT AP PARATUSES, 
WHERBN THE CUEMT APPARATUSES ARE ADAPTED TO BE CONNECTED TO A HOST 
COMPUTER VIAA NETWORK 
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STORING INFORMATION ON THE HOST COMPUTER FOR AUOWING THE SIMULTANEOUS 
PLAYBACK OF THE EVENT ON EACH OF THE CLIENT APPARATUSES 
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AaOWING THE INFORMATION TO BE DOWNLOADED UTtUZiUG THE NETWORK FOR 
PLAYBACKAFTER THE SIMULTANEOUS PLAYBACK 
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Figure 3 



CONNECrriNG A PLURALTTY OF CUENT APPARATUSES VIA A NETWORK 
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SIMULTANEOUSLY PUYING B/^ AN EVENT ON THE CUENT APPARATUSES UTILIZING 

THE NETWORK 
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OVERLAYING MATERIAL DURING THE PLAYBACK OFTHE EVENT BASED ON INPUT 
RECEIVED FROM AT LEAST ONE OFTHE CUEMTAPPARATUSES 
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CONrffiCTING A PtUfMUrrOF CUBirAPPARA-nJSESVlAAhlETVWiRK. WHEREIN AN 
EVENT iS SrOKED B4 MBIIIORy ON THE CUENT APPARATUSES 



500 



SIMWLTANEOUSLYPIAYING BACKTHE EVENT ON THE CUENT APPARATUSES UTIUZINS 

THE NETWORK 
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RECEIVING A REQUEST FROM ONE OFTHE CUENT APPAIWR^KKWUNGTH 
SIMULTANEOUS PlAYaACKTO BE INCIUDED W THE SYNCHRONIZED EVENT 



TRANSMrmNG INFORMATION TO THE REQUESTOJGCUEMTAPPARATUS UTILIZINSTHE 

MCTWRK^oSir^NQ AWtaOT^ IN THE MEMORY WHERE THE EVENT IS 
CURraSaYBBNG PUYED BACKSOAS TO AUjOWTHE SIMULTANEOUS PLAYBACK OF 
THE EVENT ON THE REQUESTING CUENTAPPARATUS 
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Figure 5 



CONNECrriNQ A PLURAUTYOF CUENT APPARATUSES VIA A hlETWORK 
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EMBEDDING AN APPUCAJION PROGRAM ON ASHH ONTOE NETWORK 
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REQUESllNGlNFORMATIONRVJMASERVERONTHENEWORKim^ 
APPUCA7T0N PROGRAMr WHEREOITOE INFORMATION RBATESTO AN EVENTTO BE 
PLAYED BACK SIMULTANEOUSLY ON THE CUENT APPARATUSES 
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RECEIVING ASCRIPT FOR DISPUYING THE INFORMATION 
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Figure 6 



RECBNANQ A REQUEST UTTUZING A NETWORK FOR VIEWING AN EVENT 
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QUEUING THE REQl^ST IN MEMORY 
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CREATING AN OBJECT IN RESPONSE TO THE REQUEST, THE OBJECT ADAPTEDTO 
PIAYBaScTOEEV^ SIMULTANEOUS with toe PLAYBACK 

ACTTVATON SIGNAL 
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SENDING THE OBJECTTO ONE OFTHECUENT APPARATUSES UTlLiZiNGTTfE NETWORK 
FOR BEING STORED THEREIN 
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Figure 7 



DETERMINI NG A CURRENT TIME. A START TIME WHEN AN EVENT tS TO START, AND A 
STOP TIME WHEN THE EVENT IS TO END 
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CALCUIATING A 1£NGTH OF THE EVENT BASED ON THE START TIME A^^ 
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STORING A COMMAND IN M^ORY IF ANY PORfnCW OF THE LENGTH OFTHE EVENT 
TAKES PLACE DURING A PREDETERMINED THRESH0U3 PERIOD 
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CREATING A LOOP ATTHE START TIME DURING WHICH A LAPSB) TIME OF THE EVENT IS 

TRAOCED 
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Figure 8 



raOVi DING A PUURAUTY OF EVENTS STORED MEMORT CH A PUiRAUTY OF CUENT 

APPARATUSES. THE EVENTS EACH HAVING A UNIQUE IDENHFIER ASSOCIATH) 
THEREWriH AND STORED IN THE MEMORY, WHEREIN THE (aiENT APPARATUSES ARE 
ADAPTED TO BE COUPLED TO A HOST CORfflHiTSl VIA A NETWORK 
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/^CERTAINING THE IDENTIFIER OFTHE EVE 
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COMPARING THE IDENTIFIER WHH AN IDEMTinER OF A SCHEDULED EVENT 
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BEGINNING THE PLAYBACK OF THE EVENT ON EACH OFTHE CUENT APPARATUSES IF 
THE COMPARISON RENDERS A MATU) 
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Figure 9 



IDENTIFYWGATYPE OFTHE PUYBACK DEVICE OF EACH OFTHECUENTAH'ARATUSES 
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LOOKING UPACOMMAND ASSOCIATED VVnH THE IDENTIFIED TYPE OF THE PLAYBACK 

DEVICE 
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SENDING THE COMMAND TO THE CORRESPONDItreCUEm- APPARATUS FORBEaNNWW 
ON EACH OF THE REMAINING CUSITAPPARATUSES 
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Figure 10 
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Step 2: Process Users Request 
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